The PNNI protocols are defined in the “Private Network-Network Interface Specification Version 1.1” (af-pnni-055.002, April 2002) by The ATM Forum. This document defines the PNNI protocol for use between private ATM switches, and between groups of private asynchronous transfer mode (“ATM”) switches. In general, PNNI includes two categories of protocols. First, a routing protocol is defined for distributing topology information between switches and clusters of switches. This information is used to compute paths through the network. A hierarchy mechanism ensures that this protocol scales well for large ATM networks. A key feature of the PNNI hierarchy mechanism is its ability to automatically configure itself in networks in which the address structure reflects the topology. PNNI topology and routing is based on the link-state routing technique. Second, a signalling protocol is defined for signalling, that is, message flows used to establish point-to-point and point-to-multipoint connections across the ATM network. This protocol is based on The ATM Forum's user to network interface (“UNI”) signalling, with mechanisms added to support source routing, crankback, and alternate routing of call setup requests in case of connection setup failure.
Policy routing extensions to PNNI are defined in “Policy Routing Version 1.0” (af-cs-0195.000, April 2003) by The ATM Forum. Policy routing as specified in this document gives a network administrator control over the way connections are routed across a PNNI routing domain based on network specific criteria and resource utilisation strategies. For this purpose, the concept of Network Service Categories (“NSCs”) was introduced. Specifically, policy routing allows a network administrator to manage network entity resources on a per NSC basis, in addition to the per ATM Service Category (“ASC”) basis that was already available in PNNI. In particular, in the absence of policy routing, PNNI allows nodes in a PNNI routing domain to route connections while taking into account the state of the resources of the links and nodes within that domain. This is achieved by providing each node (e.g., switch, router, etc.) with a detailed map of the available resources for each ASC supported by each network entity (e.g., link, etc.). PNNI allows an ATM network operator to partition the resources on network entities per ASC, apply different overbooking factors per ASC, or even allocate different amounts of resources to different ASCs. It is even possible to preclude connections of a given ASC to be routed on certain network entities by excluding available resources for that ASC from the network entity's advertisements. This set of features is a powerful and useful capability for service providers (“SPs”). However, as ATM networks evolve to support a greater variety of services, SPs need to be able to manage the resources inside their ATM network at a finer level. They also need to be able to implement certain control policies defining how connections are routed through a PNNI routing domain. A simple example is the capability for a SP to differentiate the resources that can be accessed by end-user generated switched virtual connections (“SVCs”) and network management system (“NMS”) generated soft permanent virtual connections (“SPVCs”). Since one of the main attributes of an SPVC service is the resiliency offered through dynamic rerouting, it is important to make sure that in a network also offering SVC service, the resources that will allow successful rerouting of SPVCs in case of a failure are not consumed by SVCs. In the absence of policy routing, the policies that can be implemented in a PNNI routing domain rely primarily on the ASC as the differentiating criteria. As the previous example shows, SPs need to be able to go beyond that. Hence, the concept of NSCs was introduced. In the above example, one could identify two NSCs: the SVC network service category and the SPVC network service category. Each NSC has different applications and needs to be managed differently.
According to Policy Routing Version 1.0, a “policy constraint” comprises the complete set of policy information associated with a given connection in order to provide service specific “directions” for connection routing. A policy constraint consists of a single policy or a list of policies stated in order of preference. Each policy consists of a set of rules that allow access, or restrict access, to tagged resources. These rules are expressed using one or two policy operators (one for “require” and one for “must avoid”), each applying to one list of NSCs (containing a list of Network entity NSCs (“Ne-NSCs”) and/or a list of Resource partition NSCs (“Rp-NSCs”)). (Note that a Ne-NSC is an NSC that applies to the whole network entity (including all resources) and advertises properties of the network entity whereas a Rp-NSC is an NSC that applies to a resource partition of a network entity, a network entity referring to a horizontal link, an uplink, a node, a spoke, a bypass or a set of reachable ATM addresses.) All the rules contained in at least one of the policies listed in a policy constraint must be met during connection routing for the connection to be progressed. When performing path selection using a policy, the topological map of the PNNI routing domain is “pruned”, leaving only the network entities and resources that match the policy. Without policy routing, the applicable generic connection admission control (“GCAC”) algorithm for a connection is performed on a set of resources equal to the resources of the entire routing domain. With policy routing, GCAC for a given connection is performed on a subset of resources that match one policy in the policy constraint associated with the connection.
In addition, “Addendum To Policy Routing V1.0 for a Policy Constraint MIB” (af-cs-0198.000, February 2004) by The ATM Forum further refines policy routing for PNNI. This specification provides a management information base (“MIB”) having a common means of defining policy constraints so that they can later be referenced by other applications. The policy constraint MIB is organized as two main tables: the “Policy Constraint Table” and the “Policy Table”. The Policy Constraint Table provides the entries that can be referenced by other MIB objects to utilize a policy constraint. Each entry in the table contains a set of up to six pointers into the Policy Table. The Policy Table specifies the operators of a policy. Associated with the Policy Table are the “Policy Network entity NSC Table” (or “policyNeNscTable”) and the “Policy Resource partition NSC Table” (or “policyRpNscTable”). These two tables contain the lists of NSCs on which the policy operators operate. To create a policy, the network management system (“NMS”) (e.g., an operator of a NMS) first creates an associated instance of a row status in a “policyEntry”, using a value of a “policyindex” that is not currently in use. Second, the NMS associates instances of Ne-NSC and Rp-NSC lists for the policyindex. Third, the NMS specifies values for the policy operators. Once the appropriate instance of all configuration objects have been created for the policyEntry, policyRpNscEntry, and the policyNeNscEntry (as appropriate), the row status of the policyEntry is set to active to activate the policy.
One problem with current PNNI based networks implementing the above specifications is that particular SVC-based switched service calls from a single user to network interface (“UNI”) or network to network interface (“NNI”) from network equipment that does not support policy routing, cannot be targeted to specific trunk group partitions or make use of specific network resources through policy routing on a per call or per service basis (e.g., user A's calls get policy Y and user B's calls get policy X). In particular, it is not possible to select appropriate policies that can be added to SVC-based calls to allow for proper path selection of network resources for such calls. In addition, it is possible that some SVC-based calls (e.g., user calls from customer premises equipment not supporting policy routing) may be permanently blocked as a result of all of the available bandwidth being used by another type of service (e.g., SPVCs after a reroute) as policies cannot be added to SVC-based calls on a per call or per service basis. In summary, SVC-based calls cannot be prioritized (from a network usage point of view) at the call level to participate in policy-based routing based on the called or calling party numbers (and subsequently the associated SVC service). This is problematic in that some SPs require the ability to select paths across regions based on calling or called party numbers.
A need therefore exists for an improved method and system for policy-based routing in a private network-to-network interface (“PNNI”) based network. Accordingly, a solution that addresses, at least in part, the above and other shortcomings is desired.